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Reliable Server Pooling Policies 
Status of This Memo 


This memo defines an Experimental Protocol for the Internet 
community. It does not specify an Internet standard of any kind. 
Discussion and suggestions for improvement are requested. 
Distribution of this memo is unlimited. 


Abstract 


This document describes server pool policies for Reliable Server 
Pooling (RSerPool) including considerations for implementing them at 
Endpoint Handlespace Redundancy Protocol (ENRP) servers and pool 
users. 
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Introduction 


The protocols defined in [RFC5353], [RFC5352], and [RFC5354] support 
a variety of server policies. Some of the policies use dynamic load 
information of the pool elements and others do not. Therefore, we 
classify them as adaptive and non-adaptive. The selection of the 
pool element is performed by two different entities, the ENRP server 
and the pool user. Some of the consequences for policies that are 
not stateless are described in [ICN2005] and [LCN2005]. 


Therefore, this document describes not only packet formats but also 
gives a detailed description of the procedures to be followed at the 
ENRP servers and the pool users to implement each server policy. 


Conventions 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in [RFC2119]. 


Terminology and Definitions 
1. Load 


The term load is a value specifying how much a pool element's 
resources are currently utilized. 0x00000000 states that the pool 
element is not utilized (0%); Oxffffffff states that it is fully 
utilized (100%). Defining what utilization means is application- 
dependent and out of the scope of RSerPool. However, it is required 
that all pool elements of the same pool using load information have 
the same definition of load. 


For example, load may define the current amount of users out of a 
maximum on an FTP server, the CPU usage of a database server, or the 
memory utilization of a compute service. 


.2. Weight 


Weight defines a pool element’s service capacity relative to other 
pool elements of the same pool. Theoretically, there is no upper 
limit for weight values (although limited by datatype size). 
Defining what value weights compare is application-dependent and out 
of the scope of RSerPool. However, it is required that all pool 
elements of the same pool using weight information have the same 
definition of weight. 
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A weight of 0 denotes that the pool element is not capable of 
providing any service; a higher weight denotes that the pool element 
is capable of providing better service than a pool element having a 
lower weight. 


For example, weight may define a compute service’s computation 
capacity. That is, a pool element of weight 100 will complete a work 
package in half the time compared to a pool element of weight 50. 


4. Non-Adaptive Policies 
4.1. Round Robin Policy 
4.1.1. Description 


The Round Robin (RR) policy is a very simple and efficient policy 
that requires state. This policy is denoted as the default policy 
and MUST be supported by all RSerPool components. 


4.1.2. ENRP Server Considerations 


The ENRP server SHOULD hold the pool elements of each server pool in 
a circular list and SHOULD store a pointer to one of the elements, 
called the head. On reception of a handle resolution request, the 
ENRP server SHOULD return the pool elements from the circular list, 
starting with head. Then the head SHOULD be advanced by one element. 


Using this algorithm ensures that not all lists presented to the pool 
users start with the same element. 


4.1.3. Pool User Considerations 


A pool user SHOULD use the list of pool elements returned by the ENRP 
server in a round robin fashion, starting with the first. If all 
elements of the list have been used, it should start from the 
beginning again until the information is out of date. 


4.1.4. Pool Member Selection Policy Parameter 


0 1 2 3 
012345678°9012345678°901234567890 1 
Hott t— ttt ttt o o ho o ooo ++ 

| Param Type = 0x8 | Length = 0x8 

Hotbot tit e +H 
| Policy Type = 0x00000001 | 
E e e o oo ooo ++ 
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4.2. Weighted Round Robin Policy 
4.2.1. Description 


The Weighted Round Robin (WRR) policy is a generalization of the RR 
policy. If all weights are 1, then WRR is just RR. 


4.2.2. ENRP Server Considerations 


The ENRP server SHOULD follow the same rules as RR but initialize and 
modify the circular list differently. The ENRP server puts each pool 
element, possibly, multiple times into the list such that: 


o The ratio of the number of occurrences of a pool element to the 
list length is the same as the ratio of the weight of that pool 
element to the sum of weights. 


o The multiple entries of each pool element should be as evenly 
distributed as possible in the circular list. 


4.2.3. Pool User Considerations 
The pool user SHOULD follow the same rules as RR. 
4.2.4. Pool Member Selection Policy Parameter 
0 pi 2 3 
Or 2 34S: Oe F282 9°01 2. 3 A6 T 89 0 1:23:45 6: B95 L 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Param Type = 0x8 | Length = 0xc 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Policy Type = 0x00000002 | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Weight | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


o Weight (32 bits, unsigned integer): Weight constant for the WRR 
process. 


4.3. Random Policy 
4.3.1. Description 


The Random (RAND) policy is a very simple stateless policy. 
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4.3.2. ENRP Server Considerations 


The ENRP server selects, at most, the requested number of pool 
elements from the list of pool elements. Each element MUST NOT be 
reported more than once to the pool user. 


4.3.3. Pool User Considerations 


Each time the pool user must select one pool element, it does this by 
randomly selecting one element from the list of pool elements 
received from the ENRP server. 


4.3.4. Pool Member Selection Policy Parameter 


0 1 2 3 
01234567890123456789012345678901 
$ hh RO A dd de e e e de de dd dd de 4 4 4 4 + + + ++ + ++ +++ 
| Param Type = 0x8 | Length = 0x8 
+ hh RO A RO dd de e de de de dd dd de 4 4 4 4 + + + ++ + ++ +++ 
| Policy Type = 0x00000003 | 
$ hh RO Rd q dd de de dd dd dd de 4 4 4 4 + + + +++ ++ +++ 


4.4. Weighted Random Policy 

4.4.1. Description 
The Weighted Random (WRAND) policy is a generalization of the RAND 
policy, adding a weight for each pool element entry. RAND is equal 
to WRAND having all weights set to 1. 

4.4.2. ENRP Server Considerations 
The ENRP server SHOULD select, at most, the requested number of pool 
elements randomly from the list of pool elements. Each element MUST 
NOT be reported more than once to the pool user. The probability of 
selecting a pool element should be the ratio of the weight of that 
pool element to the sum of weights. 

4.4.3. Pool User Considerations 
Each time the pool user must select one pool element, it does this by 


randomly selecting one element from the list of pool elements 
received from the ENRP server. 
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0.1.2°.3°4,.9 6 7-8 9 0 12°34 -°5°6 7.8 9:0. 1 2.3.4 5.6 7-8 9 OL 


+—4+-4+-4+-4+-4+-4+-4- 
| Param Type 
+-+-+-+-+-+-+-+- 


| 
+-+-+-+-+-+-+-+- 
| 


+-+-+-+-+-+-+-+- 


o Weight (32 bits, 
process. 


4.5. Priority Policy 
4.5.1. Description 


The Priority (PRIO) 


+-+-+-+-+-+-+-+- 


+-+-+-+-+-+-+-+- 


+— 


+ 

0x8 | Length = 0xc 
+ 
Policy Type = 0x00000004 


Weight 


-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


unsigned integer): 


policy can be used to select always a pool 
element with the highest priority. 


4.5.2. ENRP Server Considerations 


The ENRP server MUST select the pool elements with the highest 


priorities. They MUST be reported in decreasing order. 
pool elements have the same priority, they may be listed in any 
order. 

4.5.3. Pool Element Considerations 


The pool user MUST select the active pool element with the highest 


priority. 


4.5.4. Pool Member Selection Policy Parameter 


0 


1 2 


3 


Weight constant for the WRAND 


If multiple 


012345678901234567890123456789 021 


+-+-4+-+-4-+-+-4- 


| Param Type 


+-+-+-+-+-+-+-+- 


+ 
+ 


+-+-+-+-+-+-+-+-+ 


+-+-+-+-+-+-+-+-+ 
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o Priority (32 bits, unsigned integer): Larger numbers mean higher 
priorities. 


5. Adaptive Policies 
5.1. Least Used Policy 
5.1.1. Description 


The Least Used (LU) policy uses load information provided by the pool 
elements to select the lowest-loaded pool elements within the pool. 


5.1.2. ENRP Server Considerations 


The ENRP server SHOULD select, at most, the requested number of pool 
elements. Their load values SHOULD be the lowest possible ones 
within the pool. Each element MUST NOT be reported more than once to 
the pool user. If there is a choice of equal-loaded pool elements, 
round robin selection SHOULD be made among these elements. The 
returned list of pool elements MUST be sorted in ascending order by 
load value. 


5.1.3. Pool User Considerations 


The pool user should try to use the pool elements returned from the 
list in the order returned by the ENRP server. A subsequent call for 
handle resolution may result in the same list. Therefore, it is 
RECOMMENDED for a pool user to request multiple entries in order to 
have a sufficient amount of feasible backup entries available. 


5.1.4. Pool Member Selection Policy Parameter 


0 1 2 3 
012345678901 23456789012345678090U1 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

| Param Type = 0x8 | Length = 0xc 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Policy Type = 0x40000001 | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Load | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


o Load (32 bits, unsigned integer): Current load of the pool 
element. 
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5.2. Least Used with Degradation Policy 
5.2.1. Description 


The Least Used with Degradation (LUD) policy extends the LU policy by 
a load degradation value describing the pool element’s load increment 
when a new service association is accepted. 


5.2.2. ENRP Server Considerations 


For every pool element entry, a degradation counter MUST be stored. 
When a pool element entry is added or updated by registration or re- 
registration, this counter MUST be set to 0. When an entry is 
selected for being returned to a pool user, the internal degradation 
counter MUST be incremented by 1. The selection of pool element 
entries is handled like for LU, except that the selected pool element 
entries SHOULD have the lowest possible sum of load value + 
degradation counter * load degradation value. 


5.2.3. Pool User Considerations 
See LU policy. 
5.2.4. Pool Member Selection Policy Parameter 


0 1 2 3 
OL 23436: 78 9° 0 12342 Gb T 8. 90 1 2 3a D> 6.07 89-0 1 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

| Param Type = 0x8 | Length = 0x10 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Policy Type = 0x40000002 | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Load | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Load Degradation | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


o Load (32 bits, unsigned integer): Current load of the pool 
element. 


o Load Degradation (32 bits, unsigned integer): Load Degradation 
constant of the pool element. 
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5.3. Priority Least Used Policy 
5.3.1. Description 


The Priority Least Used (PLU) policy uses load information provided 
by the pool elements to select the lowest-loaded pool elements within 
the pool under the assumption that a new application request is 
accepted by the pool elements. Therefore, the pool elements also 
have to specify load degradation information. 


Example: Pool elements A and B are loaded by 50%, but the load of A 
will increase due to a new application request only by 10% while B 
will be fully loaded. PLU allows the specification of this load 
degradation in the policy information; the selection is made on the 
lowest sum of load and degradation value. That is, A will be 
selected (50+10=60) instead of B (50+50=100). 


5.3.2. ENRP Server Considerations 


The ENRP server SHOULD select, at most, the requested number of pool 
elements. Their sums of load + degradation SHOULD be the lowest 
possible ones within the pool. Each element MUST NOT be reported 
more than once to the pool user. If there is a choice of equal- 
valued pool element entries, round robin SHOULD be made among these 
elements. The returned list of pool elements MUST be sorted 
ascending by the sum of load and degradation value. 


5.3.3. Pool User Considerations 


The pool user should try to use the pool elements returned from the 
list in the order returned by the ENRP server. A subsequent call for 
handle resolution may result in the same list. Therefore, it is 
RECOMMENDED for a pool user to request multiple entries in order to 
have a sufficient amount of feasible backup entries available. 


5.3.4. Pool Member Selection Policy Parameter 


0 1 2 3 
01234567890123456789012345678090 m1 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

| Param Type = 0x8 | Length = 0x10 

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Policy Type = 0x40000003 | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Load | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Load Degradation | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


Dreibholz & Tuexen Experimental [Page 10] 


RFC 5356 RSerPool Policies September 2008 


6. 


o Load (32 bits, unsigned integer): Current load of the pool 
element. 


o Load Degradation (32 bits, unsigned integer): Load Degradation 
constant of the pool element. 


-4. Randomized Least Used Policy 


.4.1. Description 
The Randomized Least Used (RLU) policy combines LU and WRAND. That 
is, the pool element entries are selected randomly. The probability 
for a pool element entry A, utilized with load_A, to be selected is 
(OxFFFFFFFF - load_A) / (sum(0xFFFFFFFF-load_x)), i.e., this PE’s 
unload part related to the whole pool unload rate. 
.4.2. ENRP Server Considerations 
The ENRP server SHOULD behave like WRAND, having every PE’s weight 
set to (Oxffffffff -- load value provided by the pool element). 
.4.3. Pool User Considerations 
See WRAND policy. 
.4.4. Pool Member Selection Policy Parameter 
0 1 2 3 
O TZ 3 40 68 8 O OL ZA BOO. ZA 68 9 Oe 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Param Type = 0x8 | Length = 0xc 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Policy Type = 0x40000004 | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Load | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
o Load (32 bits, unsigned integer): Current load of the pool 
element. 
Security Considerations 


The security threats regarding RSerPool have been analyzed in 
RSerPool threats [RFC5355]. The server policy descriptions in this 
document do not add any other threats. 
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7. 


IANA Considerations 


This document (RFC 5356) is the reference for all registrations 
described in this section. All registrations have been listed on the 
RSerPool Parameters page. 


A New Table for RSerPool Policy Types 


RSerPool policy types that are 4-byte values are maintained by IANA. 
The format of the policy type value is defined as follows: 


o 


0 1 2 3 
001,2 3:4 030: 6: 78:90 11:23 4 56:78:90. 1,2345 6:78. 9701 
dh A A A A A O O A O dh o o o o o o +++ 
Ix|a]l Policy Number | 
dh A A A O O O o o o o o o +++ 


X: If set to 1, the policy is user defined and not standardized. 
All standards policies reserved by the IETF use X=0. 


A: If set to 1, the policy is adaptive. Otherwise, it is non- 
adaptive. 


Policy Number: The actual number of the policy. 


Nine initial policy types have been assigned and are maintained in a 
new table, "RSerPool Policy Types": 
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Value Policy Reference 
0x00000000 (reserved, invalid value) RFC 5356 
0x00000001 Round Robin RFC 5356 
0x00000002 Weighted Round Robin RFC 5356 
0x00000003 Random RFC 5356 
0x00000004 Weighted Random RFC 5356 
0x00000005 Priority RFC 5356 
0x00000006 (reserved by IETF) RFC 5356 
Ox3fffffff (reserved by IETF) RFC 5356 
0x40000000 (reserved, invalid value) RFC 5356 
0x40000001 Least Used RFC 5356 
0x40000002 Least Used with Degradation RFC 5356 
0x40000003 Priority Least Used RFC 5356 
0x40000004 Randomized Least Used RFC 5356 
0x40000005 (reserved by IETF) RFC 5356 
Ox7fffffff (reserved by IETF) RFC 5356 
0x80000000 (private use, non-standard policy) RFC 5356 
Oxffffffff (private use, non-standard policy) RFC 5356 


Requests to register an RSerPool policy type in this table should be 
sent to IANA. The number must be unique and use the appropriate 
upper bits. The "Specification Required" policy of [RFC5226] MUST be 
applied. 


The policy type space from 0x80000000 to Oxffffffff is designated for 
private use. 


8. Reference Implementation 


A reference implementation of RSerPool and the policies described in 
this document is available at [RSerPoolPage] and described in 
[Dre2006]. 
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